Рубрика: Вредные советы. Антипаттерн: Class Explosion

Описание:
Когда последователи ООП и фан-клуб Мартина Фаулера добираются до кода без присмотра, в проекте возникает эффект ядерного деления: один доменный класс — и понеслась цепная реакция. Через пару спринтов система состоит из 400 классов, каждый из которых делает одну вещь, один раз, в одном месте, и больше никогда.

Симптомы:
• Кодовая база напоминает кладбище интерфейсов.
• Каждый класс делает одну вещь прикрываясь single responsibility principle.
• На прочтение логики одного HTTP эндпоинта уходит столько времени, сколько обычно требуется, чтобы сварить борщ.
• Открываешь PR — там 27 новых файлов. Один валидирует email, другой проверяет, что имя пользователя начинается с заглавной буквы и не содержит проклятий.
• Папки model, core, domain, shared, abstractions, foundation, fundamentals, common, super_common и legacy_common лежат рядом, как косточки динозавра.


Проблемы:
1. Файловая система в панике. Количество дескрипторов растёт, как зарплаты у синьоров на LinkedIn.
2. Компиляция идёт вечность. Зато можно успеть сварить второй борщ.
3. Дебаг превращается в квест. Уже нельзя просто так открыть контроллер, промотать сотни строк кода и найти таки баг в SQL запросе. приходится просматривать множесто файлов.

Лечение:
Мы нашли способ сдерживать бесконтрольное размножение классов. Всё просто: берём ArchUnit или любой другой архитектурный электрошокер и пишем жёсткое правило:

@Test
void `prevent class explosion`() {
    JavaClasses importedClasses = new ClassFileImporter().importPackages("com.yourcompany.yourapp");

    ArchRule rule = classes()
        .should()
        .haveSimpleNameEndingWith("Controller")
        .orShould()
        .haveSimpleNameEndingWith("Service")
        .orShould()
        .haveSimpleNameEndingWith("Entity")
        .orShould()
        .haveSimpleNameEndingWith("Dto");

    rule.check(importedClasses);
}

Теперь всякий, кто вздумает создать Money, UserId или ещё хуже — AggregateRoot, получит предупреждение уже на стадии сборки. А если повезёт — то и выговор.

Вывод:
Классы должны нести гордое знамя своей функции в суффиксе. Всё остальное — ересь. Пусть живут MyAwesomeController, MyAwesomeService, MyAwesomeDto, и никакой самодеятельности.

Сережа забыл добавить, что ни в коем случае незльзя доверять управление транзакциями приложению, всё только в хранимках!

Недавно принесли проект на аудит, насколько он готов для запуска в прод. Вроде бы ничего сложного: бекенд, фронт, мобилка и немного вспомогательных штук. Но оказалось, что весь этот функционал размазан по 50+ репозиториям.

• Половина репозиториев заброшена или содержит только заготовки.
• В некоторых лежат скрипты для ручного вытягивания и сборки соседних реп – это же явный признак, что что-то пошло не так.

Мы не раз говорили: если нет веских причин дробить код – начинайте с монорепозитория. Так проще контролировать зависимости, синхронизировать изменения и поддерживать проект (закон Конвея все еще работает). А когда действительно понадобится — тогда уже можно будет выдернуть кусок в отдельный репозиторий.

Я и сам когда-то плодил репы, зачем-то даже вытаскивал внутренние части приложения наружу, но даже не смог себе честно ответить зачем я так сделал. Поэтому если хотите сэкономить время разработки — не дробите заранее.

Внимание, годнота! Слушатель наших обучалок Артем протащил таки то, о чем мы говорим и теперь ищет себе коллегу.

Наша команда ищет Backend Java разработчика!

Мы работаем над современными проектами, применяя лучшие практики разработки и архитектуры.

В нашей работе мы используем:
- EventStorming — для глубокой проработки бизнес-процессов
- Clean Architecture — для построения масштабируемых и поддерживаемых приложений
- Domain Driven Design — для создания моделей, максимально соответствующих бизнесу
- Trunk-based development — для эффективной и безопасной работы с кодовой базой
- Парное программирование — для повышения качества кода, улучшения понимание кода командой

Были бы рад видеть в команде единомышленника, которому интересно работать без боли и сожалений.
Если заинтересованы пишите @artem_poskrebyshev

В личной беседе Артем сказал, что вообще топчик получился, пожалуй пригласим его на стрим, пусть все сам расскажет.

Особенно приятно когда ребята после курсв могут внедрить эти практики! Отличная работа, Артем! знаю что было не легко!

Походил слегка по собеседованиям, ужаснулся количеству вопросов про хибер (его ещё кто-то использует?!) и решил… что очередное корпоративное болото подождёт. Последние полтора года махания веслом под крики «ДАВАЙТЕ БЫСТРЕЕ!» отбили желание не только работать, но и жить.

Поэтому временно переключаюсь на творчество и эксперименты.

Что в планах?
- Видосики – уже записал несколько видосиков (есть душные, есть не очень).
- ИИ – продолжаю эксперименты, хочется довести до практического применения и показать вам
- Стримы – в планах общаться с крутыми людьми из индустрии, уже договариваемся
- Курсовой проект – самое сочное! Небольшая команда строит приложение, используя DDD, чистую архитектуру, trunk-based development, обмазывает его безопасностью, нагрузками и мониторингом, а потом пихает в условный прод. 🚀 Пока только-только стартуем, надеюсь, участники не посадят друг друга на перо.

Посмотрим что получится, занырнуть в пучину корпоративных войн и говнокода всегда успею.

Оставайтесь с нами – будет жарко! 🔥